-
Notifications
You must be signed in to change notification settings - Fork 19
topology: set wider pipeline pcm samplerate range #69
base: master
Are you sure you want to change the base?
Conversation
Setting the range wider makes aplay to be able to play configs you set in pipeline or dai. Previously the range was locked to 48kHz. Signed-off-by: Jaska Uimonen <[email protected]>
@@ -115,5 +115,5 @@ indir(`define', concat(`PIPELINE_PCM_', PIPELINE_ID), Low Latency Playback PCM_I | |||
|
|||
|
|||
# PCM capabilities supported by FW | |||
PCM_CAPABILITIES(Low Latency Playback PCM_ID, `S32_LE,S24_LE,S16_LE', 48000, 48000, 2, 2, 2, 16, 192, 16384, 65536, 65536) | |||
PCM_CAPABILITIES(Low Latency Playback PCM_ID, `S32_LE,S24_LE,S16_LE', 8000, 192000, 2, 2, 2, 16, 192, 16384, 65536, 65536) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has this been tested ? The range was locked at 48kHz for some pipelines that had no SRC where the SSP port was fixed at 48kHz. Non 48kHz rates require SRC when the SSP is running at a different rate. I think @singalsu has some examples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Topology pipe-src-playback.m4 has this range though I haven't recently tested > 48 kHz playback. There would be also need for this same change for capture from DMIC for other than 48 kHz rate. With DMIC I've successfully recorded at 8/16/32/48/64/96 kHz. 24 kHz should work too but's there some ALSA issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@singalsu can you create kernel issues for DMIC 24kHz.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was little bit unsure what Pierre wanted in his issue. The pipelines work with this patch, but if you play with different sample rate than DAI without plughw, playback will be funny->slower/faster. OTH I can add this only to the media pipeline, which will then have src just for doing nothing (if you play at DAI rate).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@juimonen if the playback is wrong speed it should be rejected by the FW. I think @plbossart was meaning it's difficult to represent 44.1kHz with a 1ms scheduling tick as 44100 / 1000 is 44.1 i.e. not an integer. The FW copier needs to copy an integer number of samples. i.e. 44.1kHz would work if it was scheduled every 441ms as 100 samples would be copied per schedule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that was Pierre's issues 59. I guess this is related to that, that you have to change the pcm range to be able to use 192kHz. But again, I'm not sure :)
Anyway, If it's ok, I will change the range only for media playback which has the SRC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@juimonen you could alos put a check in that rate is divisible by scheduling period.
This should fix:
#60
I'm not totally sure if this was what Pierre meant with fixing, but at least I could now play 192kHz in up2 with aplay. Other platforms should be tested for regression.